The DevOps ハンドブック 理論・原則・実践のすべて
https://m.media-amazon.com/images/I/51HV9j-ltBL._SY346_.jpg
市場の急速な変化への対応
顧客に対して、安定して信頼でき、セキュアなサービスを提供
IT 組織の悪循環
1. IT 運用 : 日常業務で起こる問題の多くは、複雑でドキュメント化されていない、脆いアプリケーションとインフラストラクチャに原因がある
これらが重要な収益装置だったりプロジェクトを支えている
2. 最後に破った約束のための償い : 顧客に大胆な約束をしたり、大きな収益目標を立てた経営者からの開発圧力
3. あらゆることが少しずつ難しく、時間がかかるようになっていく
1 部 3 つの道
ポイントは 3 つ
略史
1 章 アジャイル、継続的デリバリー、そして 3 つの道
ソフトウェア開発の仕事
可変性と不確実性が高く、高度な創造性と、再現できないような作業を必要とすることが多い
プロセスタイムの変動も大きい
第 2 フェーズ (テストと運用) : リーン生産と似ている 創造性と専門能力を必要とし、予測可能性と機械的な性質を追求
可変性を最小限に抑えたアウトプットの生成を目標とする
設計/開発と同時にテスト/運用を行い、高速なフローと高品質の実現を目標とする
小さなバッチサイズで仕事を進め、バリューストリームのあらゆる部分で品質を保証する必要がある
指標
2 章 ～ 4 章
2 部 スタートのための糸口
5 章 最初に手を付けるバリューストリームの選択方法
ソフトウェアサービスの分類
複雑性の緩和と信頼性と安定性の改善だけでなく、速く安全に変更できるシステムも目指す必要
改革を拡げていく理想の展開
抵抗派を明らかに
6 章 バリューストリーム内の作業を理解し、それを可視化して、組織全体に広げる
次のステップは、価値がどのように顧客に届けられるかを十分に理解すること
イノベーションのためには、日常業務を行う他の部門から独立して仕事を進められる専任の変革チームを作る必要 専任チームには、明確に定義された測定可能なシステムレベルの成果を生み出すことに専念させる
イノベーションのために
目標設定
計画期間は短く (アジャイルに)
20 % は改善に充てる
7 章 Conway の法則を念頭に置いた組織とアーキテクチャの設計
意思決定科学の分野では、組織構造には 3 つの基本種別がある 職能指向 (functional-oriented) : 専門能力の育成、活用、分業、コスト削減に適する
マトリックス指向 (matrix-oriented) : 職能指向と市場指向の 2 つの種別の結合を意図
複雑な組織構造になることが多く、職能指向の目標も市場指向の目標も達成できないことがある
市場指向 (market-oriented) : 顧客のニーズにすばやく呼応することを意図
疎結合なアーキテクチャ : チームが他のチームから独立してデプロイできるように
8 章 開発の日常業務に運用を統合してすばらしい成果を生み出す方法
一元管理的な運用チームで市場指向なチームのような特徴を実現するには？
サービスチームの開発者の生産性を上げるために、セルフサービス機能を作る
サービスチームに運用エンジニアを配置
それができないときには、運用にサービスチーム連絡担当を指名
3 部 第 1 の道 : フロー改善の技術的実践
4 部 第 2 の道 : フィードバックの技術的実践
5 部 第 3 の道 : 継続的な学習と実験の技術的実践
6 部 情報セキュリティ、変更管理、コンプライアンスを統合するための技術的実践
22 章 すべてのエンジニアの毎日の職務として情報セキュリティを位置づける
イテレーションのデモに情報セキュリティを組み込む
セキュリティ問題の追跡に、開発や運用が使う作業追跡システムを使う
セキュリティ問題が起きたらポストモーテムを行う
共有ソースコードリポジトリに、アプリケーションと環境をセキュアに保つための機構やツールも追加
デプロイパイプラインにセキュリティを統合
セキュリティテストを自動化
23 章 デプロイパイプラインを防御する
補章